[...] > eh? with solaris you an load/unload drivers and modules on the fly and > configure the kernel _while_ it is running. this you ant do with sunos, > also the svr4 kernel is far more scalable than the sunos one. the case isnt > that solaris kernels are harder to configure, its that they are different. > if you really want to compare the two kernels read the following two books > "The Magic Garden Explained" by Berny Goodheart, also "BSD Internals" (i > think not sure of the author) it is published by Addison Wesley, it has a > picture of a little devil on the front (i havea copy of the former and have > read the latter but dont have a copy as yet). Right. You can load and unload modules. These are extensions. Too bad if you want to replace something _in_ the kernel. How easy is it to repace sockmod on Solaris2 ? Or say the UFS drivers or the NFS code ? They're all hidden away in prepacked bits and pieces which you are allowed to chose from. Solaris2 might be just as (or more configurable) than SunOS4, but to me, I feel like I have more control over what is and isn't in my SunOS4 kernel. Come to Solaris2 and I have pieces that I can pick from but I am given little or no choice if I want something to do job XYZ. Strange that the best host to use as a multicast router is a machine running SunOS4, where you can replace bits of the kernel easily, no ? Maybe it is more that the BSD kernel has lots of other bits around to play with which makes it more inviting to the hacker than does the no-cc solaris2. obbug: this is relevant to the subject at least...to make more efficient use of out network numbers I recently sought to subnet 26/6, after being on a traditional boundary (24/8). There were quite a few problems in getting this to work (in terms of routing) but perhaps the most interesting change happened when I changed my broadcast address from beng all 0's to all 1's. No problem you say...well... i tried to ping the broadcast address as if it were all 0's...*poof* something was screwed, having done it remotely I lost *all* response and in going in to check up, found that all machines on that subnet were in some sort of feedback hell - the (best) solution was to unplug hosts from the ethernet, let packets die, and then plug back in. *Strangely* the only host that was (seemingly) affected was the one I executed the ping on. Weeks later I try something else; I send a broadcast udp packet to the all 0 address and what happens ? inetd complains about too many packets/service failure and shuts the service down! *1* packet was sent! Needless to say, I think I've seen the same bug using etherfind/tcpdump where the occasional broadcast (such as routing info) will appear *multiple* times for the same packet. None of this has been fatal, just *very* annoying. Leads to wonder if perhaps, services such as syslogd (non-inetd) could be shutdown or otherwise affected...I wish it were my doing, but all that was changed is subnet mask and bcast address which works fine as long as I don't use 1's...(anyone know any more on this ?) darren p.s. this strange behaviour has been observed on 4.1.[1-3]